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“Software  plays  a  major  role  in  today’s  weapon  systems.  The 
“ smarts ”  of  smart  weapons  are  provided  by  software. 
Software  is  crucial  to  intelligence,  communications, 
command  and  control.  Software  enables  computerized 
systems  for  logistics,  personnel,  and  finance.  The  chief 
“military  software  problem”  is  that  we  cannot  get  enough  of 
it,  soon  enough,  reliable  enough,  and  cheap  enough  to  meet 
the  demands  of  weapon  systems  designers  and  users.  Software 
provides  a  major  component  of  U.S.  war-fighting  capability.  ” 


Report  of  the  Defense  Science  Board 
Task  Force  on  Military  Software 
September  1987 
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EXECUTIVE  SUMMARY 

This  DoD  Software  Master  Plan  was  developed  through  the  collaborative  efforts  of  numerous 
offices  and  organizations  within  the  Department  of  Defense  (DoD)  and  under  the  auspices  of  the 
Defense  Acquisition  Board  Science  and  Technology'  Committee.  It  provides  a  consolidated 
approach  for  addressing  the  challenges  presented  to  the  DoD  today  by  the  escalating 
development,  utilization  and  cost  of  software  in  our  defense  systems.  It  identifies  specific  areas 
for  improvement  in  research,  development,  test,  deployment  and  maintenance  of  software  in 
defense  systems,  including  mission  critical  computer  systems,  automated  information  systems, 
scientific  and  engineering  systems,  and  weapons  systems.  It  also  identifies  feasible  concrete 
actions  to  accomplish  these  improvements.  _ _ . 

Throughout  the  development  of  the  plan,  the  following  underlying  assumptions  provided  the 
basis  for  the  strategy  used  in  defining  problem  areas  and  proposing  corrective  actions: 

—  The  principles  of  DoD’s  Total  Quality  Management  initiative  must  guide  the  development 
of  the  plan; 

—  The  scope  of  the  plan  should  be  limited  to  DoD  issues; 

—  A  plan  for  the  future  must  be  based  upon  a  knowledge  of  today  ; 

—  Software  demands  and  expectations  will  continue  to  increase; 

—  The  DoD  does  not  need  another  study  on  software  problems; 

—  The  plan  must  address  all  DoD  software  ; 

—  Software  must  be  viewed  as  part  of  a  total  system; 

—  System  security,  with  emphasis  on  software,  will  be  an  increasing  concern; 

—  Software  engineering  is  not  yet  a  true  engineering  discipline; 

—  The  plan  should  not  be  a  software  primer;  and 

—  Proposed  actions  must  be  explicit. 

The  means  available  to  the  DoD  to  effect  the  process  and  characteristics  of  software  include:  (a) 
software  acquisition  and  life  cycle  management;  (b)  DoD  software  policies;  (c)  personnel;  and 
(d)  the  software  technology  base  and  transition.  For  each  of  these  means,  related  problem  areas 
are  addressed,  goals  are  identified,  and  specific  actions  that  are  required  to  accomplish  those 
goals  are  enumerated. 

a.  Software  acquisition  and  life-cycle  management:  Many  of  the  problems  associated  with 
DoD’s  acquisition  and  management  of  software  sensitive  systems  can  be  attributed  to:  (1) 
the  dichotomous  oversight  structure  for  computer  resources  within  the  DoD;  and  (2)  the 
incompatibility  between  much  of  the  guidance  for  defense  management  and  acquisition 
and  the  emerging  technologies  for  modern  engineering  concepts.  The  folloyving  goals  were 
identified  for  improving  DoD’s  acquisition  and  management  of  softyvare: 

—  Revise  the  DoD  software  acquisition  management  structure; 

—  Increase  management  awareness  and  visibility  of  software  issues  and  impacts  on 
systems; 

—  Enhance  the  life-cycle  management  process  to  introduce  software  improvements; 
and 

—  Improve  the  contracting  environment. 

b.  DoD  software  policies  and  standards:  Current  software  policies,  standards  and  guidance 
must  be  more  consistent,  more  timely  with  respect  to  modern  software  engineering 
practices,  less  prone  to  misuse,  more  complete,  and  more  readily  enforced.  The  following 
goals  were  identified  for  improving  these  policies,  standards  and  guidance: 

—  Consolidate  DoD  policies  for  automated  information  systems  and  mission  critical 
systems; 

—  Update  applicable  DoD  system  policies  and  standards  to  reflect  softyvare  impacts: 

—  Update  DoD  softyvare  and  related  standards;  and 
—  Strengthen  DoD  advisory-  role  in  softyvare  export/import  policy. 
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c.  Personnel:  A  significant  shortage  of  sufficiently  qualified  software  personnel  currently 
exists  at  all  levels  within  the  DoD.  Consequently,  actions  must  be  taken  to  improve  the 
ability'  of  the  DoD  to  attract  and  retain  talented  software  professionals.  The  following 
goals  were  identified  for  increasing  the  number  of  qualified  DoD  software  personnel: 

—  Improve  personnel  policies  to  retain  and  develop  qualified  personnel ;  and 

—  Improve  education  and  training. 

d.  Software  technology  base  and  transition:  The  maintenance  of  a  strong  technology  base 
requires  sustaining  the  basic  research  activity,  brokering  technology  transition 
relationships,  advancing  an  infrastructure  for  engineering  and  prototyping,  fostering  an 
active  and  independent  basic  research  community,  and  transferring  the  technology  into 
use.  The  following  goals  were  identified  for  enhancing  the  software  technology  base  and 
improving  technology  transition: 

—  Improve  management  of  the  DoD  software  technology  base; 

—  Increase  the  software  technology  base  investment;  and 

—  Accelerate  technology  transition. 

The  following  table  provides  a  summary  of  the  priority,  funding  and  schedule  for  each  of  the 
actions  identified  within  this  plan  as  being  necessary  to  accomplish  the  goals  enumerated  above. 
Actions  are  prioritized  on  a  scale  of  #1  to  #3,  with  #1  being  most  important.  Actions  are 
identified  by  the  number /letter  pair  assigned  in  Chapters  2  through  5  and  by  a  brief  phrase, 
summarizing  the  action.  Because  it  is  not  possible  to  capture  the  full  meaning  of  each  action  in  a 
single  phrase,  the  reader  is  advised  to  refer  to  the  full  text  associated  with  each  action,  provided 
in  Chapters  2  through  5. 

The  action  determined  to  be  most  significant  in  the  implementation  of  this  DoD  Software  Master 
Plan  is  the  designation  of  an  office  by  the  Deputy  Secretary  of  Defense  to  serve  as  a  focal  point 
within  the  DoD  for  software  (Action  #2- A).  This  office  should  have  primary'  responsibility  for 
identifying,  managing,  integrating  and  implementing  software  acquisition  and  life  cycle 
management  policy.  Action  #2-A  also  calls  for  the  designation  of  a  similar  office  within  each  of 
the  DoD  components. 
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Action  Summary,  Prioritization,  Schedule,  and  Funding 


Action  Number  and  Summary 

Pri. 

FY91 

FY92 

FY93 

FY94 

FY95 

2-A  Designate  office  as  SW  focal  point 

m 

2-B  Ensure  SW  addressed  within  DAB  structure 

DP' 

ts - ^ 

2-C  Ensure  TQM  techniques  used  for  SW 

EE 

1000K 

1000K 

2-D  Define  SW  risk  management  framework 

m 

9H1 

■ 

2-E  Establish  metric  tool  "Consumer's  Union" 

m 

s 

Si 

1000K 

1000K 

1000K 

2-F  Propose  technology  insertion  projects 

EE 

8BKK 

1 

2-G  Review  acq.  &  contracting  strategies  for  SW  issues 

IE 

2-H  Initiate  cases  with  FAR  Council  on  SW  issues 

IE 

3-A  Consolidate  SW  directives/policies/guidance 

IE 

S. - j. 

s. 

3-B  Consolidate  Ada  policy  and  oversight 

IE 

3-C  Establish  system  policies  to  address  SW  supoort 

IE 

3-D  Review  system  acq.  strategies  for  SW  issues 

EE 

_ 

3-E  Update  software  and  related  standards 

KE 

3-F  Revise  software  export/imoort  policy 

KB 

■■■ 

■ 

■■■ 

4-A  Define  civilian  SW  career  paths  and  salary  incentives 

D 

/ 

4-B  Define  military  SW  career  path  to  General/Flag  rank 

IE 

-  ^ 

4-C  Dev.  service  SW  training  plans  leading  to  adv.  degree 

D 

2000K 

20C0K 

2000K 

4-D  Develop  SW  awareness  3nd  SWacq.  mgt.  courses 

m 

4-E  Develop  accredited  SE  programs 

El 

■ 

4-F  Develop  DoD  SE  scholarship  program 

m 

!P!^i 

rm 

len 

500K 

4-G  Integrate  SW  programs  into  DoD  Joint  Service  School 

El 

IHH 

4-H  Establish  SE  educational  requirements 

KE 

i«| 

- ^ 

s, 

5-A  Use  key  principles  to  evaluate  tech  base  managers 

IE 

5-B  Develop  SW  Technology  Plan 

BP 

5-C  Develop  plan  for  DoD  SW  repositories 

EP 

\mm 

5-D  Establish  SW  Information  Clearinghouse 

II 

||^| 

IRSii 

500K 

500K 

500K 

5-E  Develop  tech  transition  assessment  process 

H 

|n 

*^55552 

IBHP 

\m 

1  1 
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FOREWORD 

During  the  past  two  decades,  software  has  become  the  focus  of  functionality  and  flexibility  in 
almost  all  Department  of  Defense  (DoD)  systems.  While  there  have  been  several  laudable 
efforts  initiated  within  the  Department  to  address  software  issues  over  the  years,  the  DoD 
continues  to  encounter  significant  problems  throughout  the  life  cycle  of  its  many  systems. 

On  March  13,  1989,  Dr.  George  P.  Millburn,  Chairman  of  the  Defense  Acquisition  Board 
(DAB)  Science  and  Technology  (S&T)  Committee,  established  a  Software  Working  Group  to 
define  a  program  by  which  the  DoD  could:  (1)  provide  increasing  capabilities  for  existing  and 
emerging  systems;  and  (2)  reduce  the  costs  associated  with  the  development  and  life  cycle 
maintenance  of  software.  In  order  to  ensure  a  consolidated  DoD  approach  to  this  effort, 
membership  on  the  Software  Working  Group  was  expanded  to  include  representatives  from  all 
DoD  organizations  in  which  software  was  a  major  area  of  concern.  As  a  result,  the  Software 
Working  Group  consisted  of  representatives  from  the  following  organizations: 

•  Office  of  Under  Secretary  of  Defense  (Acquisition): 

•  Office  of  Deputy  Under  Secretary  of  Defense  (Industrial  and  International  Programs) 

•  Office  of  Director,  Program  Integration 

•  Office  of  Assistant  Secretary'  of  Defense  (Production  and  Logistics) 

•  Office  of  Deputy  Director  of  Defense  Research  and  Engineering  (Research  and 
Advanced  Technology) 

•  Office  of  Deputy'  Director  of  Defense  Research  and  Engineering  (Strategic  and  Theatre 
Nuclear  Forces) 

•  Office  of  Deputy  Director  of  Defense  Research  and  Engineering  (Tactical  Warfare 
Programs) 

•  Office  of  Deputy  Director  of  Defense  Research  and  Engineering  (Test  and  Evaluation) 

•  Office  of  Assistant  Secretary  of  Defense  (Command,  Control,  Communications  and 
Intelligence) 

•  Office  of  Assistant  Secretary  of  Defense  (Program  Analysis  and  Evaluation) 

•  Office  of  DoD  Comptroller 

•  Office  of  Director,  Operational  Test  and  Evaluation 

•  Joint  Staff 

•  Office  of  Assistant  Secretary  of  the  Army  (Research,  Development  and  Acquisition) 

•  Office  of  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition) 

•  Office  of  Assistant  Secretary  of  the  Air  Force  (Acquisition) 

•  Defense  Advanced  Research  Projects  Agency 

•  Strategic  Defense  Initiative  Organization 

•  Defense  Communications  Agency 

•  National  Security  Agency 

The  original  intent  of  the  Software  Working  Group  was  to  develop  a  DoD  Software 
“Technology”  Plan.  However,  the  majority'  of  members  soon  agreed  that  such  a  limitation  of 
scope  would  not  address  many  of  the  software  problems  being  encountered  within  the 
Department  today  that  are  the  result  of  nontechnical  factors.  As  noted  in  [ZRACKET88]: 

"Better  management  techniques  applied  to  software-intensive  projects  will  increase 
productivity  and  lower  risk  in  the  near  term.  Management  changes  can  cause  improvements 
because  the  state-of-the-practice  is  far  behind  the  state-of-the-art.  Once  that  gain  has  been 
made,  further  substantial  progress  in  software  productivity  and  quality  must  come  from 
future  technology  improvement." 

The  DoD  Software  Master  Plan  represents  the  collective  efforts  of  the  Software  Working  Group 
members,  as  well  as  the  many  individuals  within  the  DoD  who  worked  so  diligently  to  review  and 
provide  constructive  feedback  on  the  various  iterations  of  the  document.  All  contributors  were 
constrained  by  a  very  rigid  time  schedule,  driven  by  the  need  to  provide:  (1)  a  very  proactive 
approach  to  addressing  the  problems  during  a  time  of  review  and  change  within  the  Department 
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as  a  result  of  the  Defense  Management  Report  [OSD89];  and  (2)  a  timely  and  realistic  plan  that 
was  viable  for  public  scrutiny. 

Particular  recognition  and  appreciation  is  extended  to  the  representatives  of  the  following 
organizations,  who  provided  additional  inputs  to  the  Software  Working  Group  for  consideration 
in  development  of  the  plan: 

•  Aerospace  Industries  Association  of  America  (AIA) 

•  American  Institute  of  Astronautics  &  Aeronautics  (AIAA) 

•  American  National  Standards  Institute  (ANSI) 

•  American  Society  for  Quality  Control  (ASQC) 

•  Armed  Forces  Communications  &  Electronics  Association  (AFCEA) 

•  Association  for  Computing  Machinery  (ACM) 

•  Data  Processing  Management  Association  (DPMA) 

•  Electronics  Industries  Association  (EIA) 

•  Institute  for  Electrical  &  Electronic  Engineers  (IEEE) 

•  National  Security  Industrial  Association  (NSIA) 

•  Society  of  Automotive  Engineers  (SAE) 

•  X/OPEN 

This  document  is  provided  in  two  volumes.  Volume  I  (consisting  of  Chapters  1  through  6) 
provides  the  basic  plan  of  action  for  the  DoD.  It  is  organized  around  the  primary  means  by 
which  the  DoD  can  effect  the  process  and  characteristics  of  software:  management,  policy, 
personnel,  and  technology.  Each  of  these  is  treated  individually  in  Chapters  2  through  5  which 
provide  detailed  discussion  and  rationale  for  specific  actions  that  are  required  within  the  DoD. 
Each  action  identifies  one  or  more  individuals,  offices,  or  components  to  carry'  out  that  action, 
as  well  as  a  priority  and  an  estimate  of  time  and  cost  required.  A  start  date  of  fiscal  year  1991  is 
used  as  the  basis  for  scheduling.  Chapter  6  provides  a  summary,  priority,  funding  and  schedule 
for  each  of  the  required  actions  identified  in  Chapters  2  through  5. 

Volume  II  (consisting  of  Annexes  A  through  G)  provides  background  information  gathered 
from  the  contributing  DoD  components  during  the  development  of  this  plan.  It  represents  the 
current  status  of  various  aspects  of  the  DoD  with  regard  to  software.  Annex  A  provides  a 
description  of  the  current  software  management  roles  of  offices  and  organizations  within  the 
DoD.  Annex  B  provides  a  listing  and  description  of  the  many  existing  DoD  policies,  standards 
and  guidance  documents  regarding  software  and  systems.  Ann-  x  C  provides  a  description  of 
current  software  research  and  development  efforts  within  the  DoD.  Annex  D  provides  a 
description  of  a  number  of  cross-cutting  issues  of  critical  importance  to  the  DoD  that  are  not 
easily  discussed  in  the  framework  of  Volume  I.  Annex  E  provides  a  summary  review  of  twelve 
previous  studies  on  software  issues  and  identifies  actions  that  have  been  taken  thus  far  w’ithin  the 
DoD  as  a  result  (direct  or  indirect)  of  such  software  studies.  The  material  provided  by  these 
Annexes  was  instrumental  in  the  identification  of  issues  and  formulation  of  corrective  actions 
enumerated  within  Volume  I.  Supplemental  Annexes  F  and  G  provide  a  list  of  references  and 
acronyms,  respectively.  Volume  II  is  germane  to  understanding  the  factors  considered  during  the 
development  of  the  basic  plan  provided  in  Volume  I. 
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1.  INTRODUCTION 

1.1  Purpose 

The  Department  of  Defense  (DoD)  Software  Master  Plan  documents  a  consolidated  DoD 
approach  to  addressing  the  challenges  presented  by  the  escalating  development,  utilization  and 
cost  of  software  in  our  defense  systems.  It  identifies  specific  areas  for  improvement  in  research, 
development,  test,  deployment  and  maintenance  of  software  in  defense  systems,  including 
mission  critical  computer  systems,  automated  information  systems,  scientific  and  engineering 
systems,  and  weapons  systems.  It  also  identifies  feasible  concrete  actions  to  accomplish  these 
improvements. 

1.2  Background 

Software  is  defined  to  be  those  computer  programs,  procedures,  rules,  and  associated 
documentation  and  data,  pertaining  to  the  operation  of  a  computer  system.  In  the  past  several 
decades,  software  technolog)’  has  played  an  increasingly  larger  role  in  maintaining  our  military 
superiority.  In  fact,  the  DoD  Critical  Technologies  Plan  [DOD89]  identifies  software 
producibility  as  one  of  the  most  critical  technologies  impacting  the  DoD  today.  From  weapons 
systems  to  payroll  systems  and  from  inventory  management  to  intelligence  activities,  there  is  a 
steadily  increasing  reliance  on  software  technology  across  all  aspects  of  defense  activities.  There 
are  several  major  impacts  resulting  from  this  increasing  reliance: 

1.  Organizational  Impact:  The  increasing  automation  of  capabilities  throughout  the  DoD  is 
fundamentally  changing  the  character  of  the  DoD  and  the  missions  of  its  individual 
organizations.  Automation  is  not  simply  the  process  of  replacing  existing  equipment  and 
weapons  with  automated  versions  but  also  includes  the  process  of  enabling  capabilities  that 
were  previously  impossible.  Because  of  technological  advances,  high  level  commanders, 
including  the  President,  now  expect  to  have  information  to  survey  individual  situations  and 
to  direct  sophisticated  operations  remotely.  Such  a  capability  creates  new  mission 
relationships  and  pervasive  interoperability  and  security  demands.  Thus,  the  introduction 
of  new  capabilities  through  automation  creates  organizational  changes  which  then  require 
additional  new  capabilities. 

2.  System  Requirements  Impact:  Increasing  computer  technology  capabilities  have  led  to 
growing  expectations  and  demands  for  system  functionality.  These,  in  turn,  have  led  to 
expanding  software  requirements.  These  requirements  have  evolved  from:  (1)  the  use  of 
advancing  technologies,  including  processing  capabilities,  by  system  designers  to  create 
more  complex  systems;  and  (2)  the  allocation  of  a  larger  percentage  of  system  complexity 
to  software  in  order  to  maximize  system  flexibility.  This  combination  of  trends  was  noted 
in  [ZRACKET88]: 

“The  size  and  complexity  of  this  software  has  been  growing  exponentially,  because 
designers  choose  to  implement  needs  of  the  increased  functional  complexity  of 
these  systems  in  software” 

Since  the  ailocation  of  system  complexity  to  software  is  increasing,  a  large  percentage  of 
system  problems  are  often  perceived  as  software  problems.  Further,  the  size  and  cost  of 
designing,  creating,  and  deploying  this  software  is  increasing  with  its  complexity.  As  noted 
in  [Tenenbaum87j: 

“Growth  in  the  numbers,  speed,  and  power  of  the  embedded  hardware  has 
increased  the  length  and  complexity  of  the  software  to  run  the  computers.  The  F-16D 
has  236,000  lines  of  code...  It  is  estimated  that  the  ATF  (Advanced  Tactical 
Fighter)  will  require  as  many  as  seven  million  lines  of  code. ..” 

Further,  even  after  systems  are  deployed,  the  DoD  must  possess  the  critical  capabilities  to 
maintain  and  evolve  the  software  in  these  complex  systems  throughout  the  system's  life 
cycle. 
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3.  System  Acquisition  Impact:  The  contracting  and  management  mechanisms,  data  rights 
options,  and  support  approaches  are  all  being  impacted  by  the  increase  in  software  demand 
and  the  introduction  of  commercial  off-the-shelf  (COTS)  software  into  the  military 
domain.  As  stated  in  [HOUSE89]: 

“Computer  software,  which  is  now  a  major  cost  item  in  many  procurements,  is 
not  immune  from  traditional  procurement  problems  such  as  delay,  cost  overruns 
and  poor  performance.  Worse,  the  procurement  system  as  presently  structured 
does  not  take  into  account  the  special  needs  of  computer  software  systems 
and  can  compromise  effective  software  development  from  the  start.” 

4.  System  Life-Cycle  Impact:  In  addition  to  the  direct  impact  of  software  as  part  of  a  system, 
software  tools  are  beginning  to  play  a  major  role  in  the  support  of  the  system  design, 
development,  test,  evaluation,  operations,  and  maintenance  processes.  Software  tools  now 
available  in  limited  domains  support  the  specification  and  immediate  evaluation  of  a 
system  design,  thus  supporting  the  iterative  refinement  critical  to  achieving  optimal 
designs.  Separately  developed  and  managed  systems  must  be  combined  to  satisfy 
operational  requirements.  Use  of  automated  tools  will  be  needed  to  isolate  and  resolve 
problems  and  reliably  make  changes  in  these  integrated  environments. 

5.  Software  Implementation  Impact:  The  increased  demand  for  complex  software,  the  need 
to  take  advantage  of  dynamic  enhancements  in  computer  hardware  technology,  and  the 
desire  for  competitive  procurements  are  intrinsic  to  the  DoD  environment.  As  a  result, 
DoD  must  protect  its  investment  in  software  across  different  hardware  platforms  while 
amortizing  its  cost  over  the  largest  possible  user  base.  This  will  result  in  the  increased 
importance  of  software  that  is  reusable,  portable,  and  built  on  COTS  products  which  takes 
advantage  of  standards  in  an  open  systems  environment. 

6.  Software  Security  Impact:  While  computer  security  is  emerging  as  a  critical  issue  in 
defense  systems,  progress  in  the  area  has  not  kept  pace  with  needs.  DoD’s  increasing 
reliance  on  software  makes  it  imperative  that  the  software  not  only  act  as  specified,  but  is 
also  not  easily  subverted  or  compromised. 

The  DoD  requires  an  effective  way  to  focus  management  attention  on,  and  deal  with,  software 
issues.  It  must  recognize  that  the  root  cause  is  not  simply  software  oriented,  but  a  direct  result 
of  deficiencies  within  the  overall  DoD  system.  In  order  to  address  these  deficiencies,  specific 
actions  must  be  taken  in  the  following  areas:  (1)  software  acquisition  and  life  cycle  management; 
(2)  DoD  software  policies,  standards,  and  guidance;  (3)  personnel;  and  (4)  the  software 
technology  base  and  software  technology  transition.  This  plan  addresses  each  one  of  these  areas 
and  identifies  specific  actions  for  improvement.  However,  there  are  several  highly  visible  and 
critical  issues  that  must  be  addressed  across  these  areas.  They  include  the  software  process, 
software  reuse,  high  assurance  and  secure/trusted  software,  real-time  software,  and  parallel  and 
distributed  software.  Annex  D  provides  a  high-level  review  of  these  cross-cutting  issues  as 
background  and  motivation  for  the  required  actions  of  Volume  I. 

1.3  Assumptions 

Throughout  the  development  of  this  plan,  there  were  several  underlying  assumptions  upon  which 
the  strategy  for  defining  problem  areas  and  proposing  corrective  actions  was  based.  These 
assumptions  are  summarized  in  the  following  sections. 

1.3.1  The  Principles  Of  DoD’s  Total  Quality  Management  Initiative  Must  Guide  The 
Development  Of  The  Plan 

Quality  requires  a  commitment  to  continuous  improvement  by  all  DoD  personnel.  The  current 
DoD  Total  Quality  Management  (TQM)  initiative  emphasizes  the  importance  of  teamwork, 
improved  communications  DoD-wide,  managers’  participation  in  the  policy  making  process, 
innovation,  integrity  and  accountability.  The  development  of  the  DoD  Software  Master  Plan 
must  be  guided  by  these  same  basic  principles.  However,  the  application  of  these  principles  in 
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order  to  effect  change  in  the  acquisition  process  will  encounter  several  problems.  As  noted  in 
[BETTI89]: 

1  anticipate  four  problems  in  effecting  change. 

First  of  all,  impatience.  We  all  have  a  predilection  for  quick  fixes,  a  need  to  see  immediate 
results.  But  as  Secretary  of  Defense  Dick  Cheney  has  said,  there  is  no  silver  bullet  for 
success.  Reform  will  be  a  long,  slow,  arduous  process. 

The  second  problem  will  be  resistance.  Defenders  of  the  status  quo  are  always  threatened 
by  the  prospect  of  change.  It  will  take  consistency,  constancy  of  purpose,  tenacity  and 
perseverance  to  bring  about  the  needed  reforms. 

Third,  parochialism.  Everyone  who  has  a  stake  in  the  process — DoD,  Congress  and 
industry — must  be  committed  to  optimizing  the  overall  process,  even  when  a  specific 
solution  may  not  be  optimum  from  their  particular  viewpoint. 

Fourth,  superficiality.  We  must  differentiate  between  treating  the  symptoms  and  treating  the 
root  causes.  Above  all,  we  must  be  careful  not  to  mistake  activity  for  accomplishment. 

These  same  problems  will  be  faced  by  those  within  the  DoD  who  attempt  to  effect  change 
regarding  software. 

1.3.2  The  Scope  Of  The  Plan  Should  Be  Limited  To  DoD  Issues 

While  issues  associated  with  software  certainly  impact  other  federal  departments  and  agencies, 
as  well  as  the  industrial,  academic  and  international  sectors,  the  DoD  must  first  develop  its  own 
Master  Plan  to  deal  with  these  issues  within  the  Department.  A  consolidated  DoD  Software 
Master  Plan  can  then  be  considered  as  representative  of  the  Department  in  the  development  of  a 
future  federal  or  national  software  initiative. 

Limiting  the  scope  to  the  DoD  does  not,  however,  preclude  the  involvement  of  non-DoD 
personnel  in  its  development.  Drafts  of  the  document  should  be  widely  distributed,  and 
feedback  from  the  community'  should  be  strongly  encouraged. 

1.3.3  A  Plan  For  The  Future  Must  Be  Based  Upon  A  Knowledge  Of  Today 

A  plan  that  will  ultimately  impact  almost  every  sector  of  the  defense  community  must  be  based 
upon  a  clear  assessment  of  the  problem  areas  as  they  exist  today.  That  assessment  can  only  be 
accomplished  following  a  comprehensive  review  of  the  major  areas  of  interest  and  impact. 

Recommended  actions  regarding  software  related  organizational  and  managerial  reform  cannot 
be  articulated  without  an  understanding  of  the  current  organizational  structure  and  managerial 
responsibilities.  Recommended  actions  regarding  policy  changes  and  reform  cannot  be  defined 
without  an  appreciation  for  the  myriad  (and  often  conflicting)  guidance  currently  imposed  w  ithin 
the  DoD.  Recommended  actions  regarding  technology  based  initiatives  cannot  be  proposed 
unless  current  technological  requirements  and/or  voids  can  be  demonstrated.  This  primary 
assumption  was  the  basis  for  the  development  of  the  background  information  included  within 
Annexes  A,  B,  C  and  D. 

1.3.4  Software  Demands  And  Expectations  Will  Continue  To  Increase 

The  environment  in  wnich  the  DoD  must  operate  is  constantly  changing.  Many  of  these  changes 
will  have  an  impact  on  software  demands  and  expectations: 

•  Eastern  European  and  Third  World  trends  will  lead  to  a  proliferation  of  less  predictable 
threats  to  challenge  DoD.  Coping  with  these  threats  requires  more  flexible,  interoperable, 
secure,  and  reliable  CT,  which  is  software  intensive. 

•  Reduced  DoD  budgets  will  increase  automation  needs  to  reduce  inefficiencies  and  personnel 
costs,  thus  creating  further  demands  on  software.  Affordability  will  drive  DoD  toward 
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common  modular  components,  with  flexible  software  support. 

•  A  reduced  DoD  worldwide  presence  increases  the  importance  of  rapid  mobilization  and 
deployment,  which  rely  critically  on  software  planning  and  logistics  support. 

•  Reduced  DoD  manpower  levels  imply  the  need  for  more  automated  and  semiautomated 
systems  to  maintain  force  effectiveness. 

•  Increased  networking  of  DoD  systems  places  escalating  strains  on  computer  and  software 
security'  capabilities. 

1.3.5  The  DoD  Does  Not  Need  Another  Study  On  Software  Problems 

In  general,  the  problems  associated  with  software  within  the  DoD  have  been  recognized  and 
addressed  for  many  years  through  various  studies,  often  sponsored  by  the  DoD.  These  studies, 
accomplished  by  highly  knowledgeable  and  credible  individuals  and  organizations,  provide  a 
basis  from  which  specific  actions  can  be  identified.  DoD  resources  should  not  be  expended  to 
repeat  the  effort  of  conducting  a  study  on  the  problems  associated  with  software  within  the  DoD. 
Resources  should  instead  be  allocated  to  the  task  of  capitalizing  on  those  studies  by  reviewing 
their  respective  assessments,  conclusions,  and  recommendations  as  a  precursor  to  the 
identification  of  specific  actions  to  be  accomplished  within  the  DoD.  This  assumption  was  the 
basis  for  the  development  of  background  information  in  Annex  E. 

1.3.6  The  Plan  Must  Address  All  DoD  Software 

Because  software  problems  within  the  DoD  are  pervasive  across  the  Department,  and  not 
specific  to  one  particular  class  of  defense  system,  the  plan  should  not  be  restricted  to  discussing 
only  mission  critical  computer  resources,  automated  information  systems  (AIS),  scientific  and 
engineering  systems,  or  weapons  systems.  For  the  primary  purpose  of  addressing  all  such 
systems,  the  term  “software  sensitive”  is  used  throughout  this  plan. 

1.3.7  Software  Must  Be  View  ed  As  Part  Of  A  Total  System 

Although  software  is  perceived  as  distinct  from  hardware,  it  does  not  stand  alone  and  must, 
therefore,  be  viewed  as  part  of  a  total  system.  The  software  engineering  process  is  part  of  the 
overall  systems  engineering  process  which  is,  in  turn,  part  of  the  systems  acquisition  process. 
As  such,  any  initiatives  to  improve  the  software  process  must  be  consistent  with  efforts  in  the 
parent  process  in  order  to  realize  effective  change. 

Software  and  hardware  are  components  of  an  overall  system,  but  there  are  unique 
characteristics  associated  with  software  that  preclude  its  being  developed  and  maintained  in  a 
manner  that  may  be  satisfactory  for  hardware.  Although  there  exist  various  forms  of 
representation  for  software  (e.g.,  text,  flow  diagrams,  etc.),  it  is  not  a  physical  substance. 
Software  has  no  process  corresponding  to  the  hardware  manufacturing  process.  For  much  of 
defense  software,  there  currently  exists  little  capability  to  capitalize  on  initial  investment,  es  one 
would  do  with  hardware,  through  quantity  of  production  and  sales.  Although  almost  even 
software  program  is  unique,  there  does  exist  the  potential  for  reuse  of  portions  of  software 
previously  designed.  The  challenge  remains  to  turn  that  potential  into  reality. 

While  measurable  tolerances  may  exist  for  hardware,  there  are  no  such  tolerances  associated 
with  software.  A  single  software  error  or  an  erroneous  assumption  in  the  initial  specification 
could  potentially  cause  a  system  to  fail,  with  possible  life  threatening  consequences.  Thus,  the 
standards  for  measuring  success  of  software  are  far  more  stringent  and  unforgiving  than  any 
associated  with  hardware.  This  is  made  even  more  difficult  by  the  physical  inability  to  test  all 
aspects  of  a  system  and  the  lack  of  a  proven  method  to  forecast  the  requirements  for  post¬ 
deployment  software  support  (PDSS). 
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1.3.8  System  Security,  With  Emphasis  On  Software,  Will  Be  An  Increasing  Concern 

Most  DoD  software,  whether  it  be  part  of  mission  criticai  or  automated  information  systems, 
requires  some  level  of  security.  DoD  system  acquisition  managers  must  address  this  issue  by 
integrating  computer  security  into  their  systems.  One  of  the  major  challenges  for  DoD  is  to 
develop  a  mindset  that  recognizes  computer  security  as  an  integral  part  of  ever)’  system 
acquisition. 

1.3.9  Software  Engineering  Is  Not  Yet  A  True  Engineering  Discipline 

The  development  of  software  is  largely  a  human  activity,  subject  to  human  behavior  and 
individual  assumptions.  The  development  of  a  software  engineering  discipline  based  on 
mathematical  principles  and  natural  physical  laws  is  still  in  its  earliest  stages.  Although  there  is 
now  considerable  accumulated  knowledge  and  experience  that  can  be  applied  to  future  systems, 
this  knowledge  still  falls  short  of  scientific  and  engineering  precision. 

1.3.10  The  Plan  Should  Not  Be  A  Software  Primer 

The  plan  should  articulate  a  course  of  action  for  the  DoD  and  provide  the  appropriate  rationale 
for  doing  so.  However,  the  efficacy  of  the  resultant  document  could  be  reduced  if  its  contents 
were  diluted  with  tutorial  information.  Every  effort  should  be  made  to  justify’  proposed  required 
actions  with  a  minimum  of  tutorial  information  and  software  specific  technical  jargon. 

1.3.11  Proposed  Actions  Must  Be  Explicit 

A  primary  deficiency  of  many  previous  software  studies  accomplished  for  the  DoD  was  that  the 
recommendations  were  too  vague  or  ambiguous.  For  that  reason,  the  plan  must  be  explicit  in 
specifying  the  priority  of  the  action,  which  office(s)  should  undertake  the  action,  how  long  that 
particular  action  is  expected  to  take,  and  what  cost  is  associated  with  that  particular  action. 
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2.  SOFTWARE  ACQUISITION  AND  LIFE  CYCLE  MANAGEMENT 

ISSUE:  Fragmented  oversight  structure  and  guidance  inhibit  utilization  of  modern  software 
technologies  by  the  DoD. 

Problems  associated  with  DoD’s  acquisition  and  management  of  software  sensitive  systems  can 
be  attributed  to  two  factors.  First,  the  dichotomous  oversight  structure  for  computer  resources 
within  DoD  has  impeded  the  transfer  of  technology  and  experiences  among  defense  systems. 
The  DoD  has  a  parallel  series  of  directives  that  are  consistent  with  the  legislative  requirements 
of  the  Brooks  Act  and  Nunn- Warner  Amendment.  Separate  classification  and  management  of 
defense  systems  along  these  lines  assumes  that  a  single  acquisition  oversight  structure  cannot 
accommodate  all  types  of  defense  software  systems.  Second,  defense  guidance  regarding 
computer  resources  has  not  kept  pace  with  technology  advances.  The  studies  listed  in  Annex  E 
suggest  that  in  order  to  correct  the  problems  associated  with  DoD’s  computer  resources, 
fundamental  changes  must  occur  in  DoD  management. 

To  alleviate  these  problems,  a  proactive  acquisition  and  life-cycle  management  process  must  be 
established  by:  (1)  revising  the  current  DoD  software  acquisition  management  structure;  (2) 
increasing  management  awareness  and  visibility'  into  the  software  aspects  of  systems;  (3) 
enhancing  the  life-cycle  management  process  to  introduce  software  improvements;  and  (4) 
improving  the  contracting  environment. 

2.1  GOAL:  Revise  DoD  Software  Acquisition  Management  Structure 

Specific  DoD  guidance  for  management  oversight  of  software  sensitive  systems  has  evolved  as  a 
result  of  the  Brooks  Act  and  the  Nunn-Warner  Amendment  (exemptions)  to  that  Act.  Though 
not  required  by  law,  the  DoD  has  traditionally  separated  its  management  oversight  of  software 
sensitive  systems.  With  certain  exceptions,  oversight  of  AIS  (Brooks  Act)  is  currently  under  the 
purview  of  DoD  Comptroller,  who  serves  as  DoD’s  senior  Information  Resources  Management 
official;  and  oversight  responsibility  for  mission  critical  systems,  including  weapons  systems 
(Nunn-Warner  Amendment)  is  currently  under  the  purview  of  the  Under  Secretary  of  Defense 
for  Acquisition,  who  is  the  Defense  Acquisition  Executive.  Guidelines  for  AIS  software 
sensitive  systems  are  enumerated  in  the  DoD  79xx  series  of  directives  and  instructions,  while 
mission-critical  systems  are  administered  under  the  auspices  of  the  DoD  5000  series  of  directives 
and  instructions.  Scientific  and  engineering  software  may  be  managed  by  either  series, 
depending  on  the  unique  circumstances  of  that  software. 

The  current  dual  oversight  process  for  software  sensitive  systems  is  inadequate  for  modern 
defense  systems  and  has  resulted  in  duplicative,  conflicting  and  artificially  fragmented 
acquisition  guidance,  policies  and  oversight  for  software  sensitive  systems.  Continuation  of  this 
approach  can  lead  to  confusion  and  misapplication  of  sound  management  principles  that 
contribute  to  reducing  risks  associated  with  development  and  acquisition  of  software  sensitive 
systems. 

The  DoD  must  ensure  that:  (1)  appropriate  and  adequate  management  attention  is  focused  on 
the  software  aspects  of  all  defense  acquisitions;  (2)  proper  vehicles  (policies,  guidelines, 
regulations)  are  in  place  which  accommodate  the  software  characteristics  and  are  in  the  best 
interests  of  both  the  DoD  and  industry;  and  (3)  that  continuing  education  regarding  the  proper 
use  of  such  vehicles  is  available  to  all  DoD  personnel.  This  requires  that  a  single  advocate, 
devoted  to  the  problems  associated  with  software  sensitive  systems-including  all  AIS,  mission- 
critical,  weapons,  and  scientific  and  engineering  systems-be  identified  within  DoD.  Existing 
guidance  needs  to  be  simplified  and  reorganized  to  establish  a  unified  approach  for  development 
and  acquisition  of  Software  sensitive  systems. 
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REQUIRED  ACTIONS: 

2-A  Designate  an  office  with  primary  responsibility  for  identifying,  managing,  integrating  and 
implementing  software  acquisition  and  life-cycle  management  policy.  This  office  will  have 
cognizance  over  all  DoD  software.  This  office  should  also  have  primary  responsibility  for 
ensuring  the  implementation  of  the  remaining  actions  enumerated  within  this  plan,  as 
decided  by  the  Deputy  Secretary  of  Defense.  DoD  components  should  take  similar  actions 
to  designate  such  an  office  within  their  respective  organizations. 

OPR:  Deputy  Secretary  of  Defense 
Estimated  time  to  accomplish:  3-6  months 
Estimated  cost:  Not  applicable 
Priority:  1 

2-B  Revise  applicable  policy  directives  and  instructions  to  ensure  that  software  considerations 
are  adequately  addressed  within  the  Defense  Acquisition  Board  (DAB)  structure. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  6-12  months 
Estimated  cost:  No  direct  costs 
Priority:  1 

2.2  GOAL:  Increase  Management  Awareness  And  Visibility  Of  Software  Issues 
And  Impacts  On  Systems 

Compounding  the  problems  related  to  oversight  of  software  sensitive  systems  is  the  reticence  of 
many  senior  acquisition  officials  to  challenge  and/or  question  computer  and  software  aspects  of 
systems  acquisition.  This  reticence  is  often  caused  by  communication  difficulties  between 
management  and  the  software  community.  These  problems  limit  the  ability  to  identify 
issues/concerns  and  to  develop  recommendations  regarding  computer  and  software  facets  of 
defense  acquisition  programs. 

Visibility  into  system  cost,  schedule,  and  performance  aspects  is  required  for  all  acquisitions. 
The  software  process  must  provide  acquisition  and  operational  managers  with  sufficient  data  to 
facilitate  assessments  of  software  costs,  schedule  and  performance,  and  the  relationship  to  (and 
impact  on)  the  respective  system  level  assessments.  A  development  process  with  effective 
control  can  support  decisions  concerning  new  commitments  with  more  predictable  results, 
thereby  enabling  more  effective  management  and  risk  control.  Also,  estimation  and  control 
techniques  enable  effective  balancing  among  trade-off  items,  such  as  degree  of  assurance, 
developer  capitalization  and  use  of  conventionalized  designs,  in  meeting  mission  objectives. 

Software  cost  estimates  in  DoD  programs  have  often  been  the  cause  of  contract  overruns  in 
DoD  systems  acquisition.  Better  visibility  of  true  software  costs  in  the  acquisition  process  will 
result  if  DoD  improves  the  collection  of  basic  software  cost  data  from  contractors,  and  monitors 
costs  with  up-to-date  software  cost  estimating  procedures.  Cost  estimation  that  does  not  address 
software  support  can  result  in  low-cost  initial  developments,  but  with  high  post-deployment 
costs.  Hence,  cost  estimation  must  include  PDSS  and  include  benefits  gained  through  the  use  of 
conventionalized  architectures  and  interfaces,  including  use  of  reusable  and  COTS  components. 

Projects  must  be  managed  with  attention  to  risks;  i.e.,  their  measurement,  control,  and 
reduction,  including  the  software  components  of  system  risk.  In  practice,  system  and  software 
managers  are  usually  engaged  in  crisis  management  and  are  unable  to  focus  on  primary  risk 
sources.  The  principal  challenge  is  to  develop  the  means  to  begin  analysis,  management  and 
reduction  of  risk  during  requirements  definition.  This  requires  that  system  managers  recognize 
and  control  software  risks  as  a  fundamental  element  of  system  risk.  It  also  requires  that 
software  mangers  have  experience  in  risk  mangemcnt  techniques. 


7 


PRELIMINARY  DRAFT 


February  9, 1990 


2-C  Ensure  Total  Quality  Management  (TQM)  techniques  for  software  life  cycle  management 
are  incorporated  into  both  program  management  and  contracts  for  modern  software 
sensitive  systems  to  support  this  action.  The  following  should  be  addressed: 

—  Initiate  a  calibration  program  to  provide  for  consistent  application  and  interpretation 
of  software  metrics  and  their  application  domains. 

—  Promulgate  a  generic  set  of  visibility  tools  for  management  use  that  provide  insight 
into  software  products  and  processes,  including  cost,  schedule,  and  performance 
parameters. 

—  Work  with  the  OSD  Cost  Analysis  Improvement  Group  to  provide  a  set  of 
recommendations  to  assure  improvements  in  the  effective  use  of  and  collection  of 
basic  software  cost  data. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  Continuous  (Baseline  in  24  months) 

Estimated  cost:  $1M  per  year 
Priority:  2 

2-1)  Develop  and  promulgate  software  risk  management  techniques  for  identifying,  assessing 
and  controlling  software  risks,  e.g.  performance,  security,  cost,  and  schedule,  throughout 
the  system  life  cycle. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  12  months  to  develop 
Estimated  cost:  $  100K 
Priority:  2 

2-E  Establish  a  DoD  software  “Consumers  Union”  to  provide  unbiased  and  independent 
evaluations  of  commercial  software  measurement  and  visibility  tools  that  can  potentially 
be  used  by  the  DoD. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  12  months  to  propose  and  select 
Estimated  cost:  $1M  per  year  to  operate  facility 
Priority:  3 

2.3  GOAL:  Enhance  The  Life-Cycle  Management  Process  (Development  And 
Post  Deployment  Software  Support)  To  Introduce  Software  Improvements 

Long-lived  software  sensitive  systems  are  often  plagued  by  insufficient  memory,  insufficient 
processor  speed,  a  software  design  that  is  not  up  to  current  practice,  an  archaic  programming 
language,  and  an  increasing  complexity  of  code  as  the  system  ages.  These  constraints  and 
factors  result  in  substantial  costs  for  post  deployment  software  support. 

Development  approaches  that  address  life-cycle  risks  and  mid-life  upgrades  of  existing  hardware 
and/or  software  could  ameliorate  these  problems.  An  investment  in  either  approach  could 
result  in  sufficient  benefit,  including  enhanced  productivity  in  software  support,  to  make  the 
investment  economically  sound.  The  investment  could  be: 

a.  Advanced  technology  oriented  to  remove  hardware  constraints ; 

b.  Upgrade  to  current  technology,  which  could  require  software  recoding  to  improve  its 
structure,  memory  usage,  etc.,  or  redesign  into  more  modem  operating  environment;  or 

c.  A  mix  which  could  involve  both  of  the  above  improvements. 

REQUIRED  ACTIONS: 

2-F  Propose  projects  to  demonstrate  strategies  for  accommodating  technology  insertion 
throughout  the  software  life  cycle.  Strategies  include  but  are  not  limited  to  a  mix  of  rapid 
prototyping,  shadow  projects  and  mid-life  upgrade  projects.  These  proposals  will  be 
part  of  the  DoD  Software  Technology  Plan  described  in  Chapter  5. 
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OPR:  OUSD(A) 

Estimated  time:  6  months 
Estimated  cost:  No  direct  costs 
Priority:  3 

2.4  GOAL:  Improve  The  Contracting  Environment 

DoD  policies  and  regulations  related  to  software,  particularly  in  the  area  of  acquisition,  often 
conflict  with  practices  acceptable  to  private  industry.  DoD  acquisitions  often  concentrate  on  the 
hardware  aspects  of  systems,  with  little  concern  for  impacts  associated  with  software.  The 
hardware-premised  acquisition  process  is  established  to  reduce  costs  associated  with  production 
of  the  system  (hardware/weapon).  This  approach  is  contrary  to  the  software  development 
process  where  costs  are  attributable  to  the  design,  development,  testing,  and  post  deployment 
support  of  the  system,  rather  than  to  the  production  of  the  system.  Contractors  desire  more 
rights  to  software  they  have  developed  and  incentives  to  use  existing  or  “reusable”  software  in 
systems. 

The  DoD  must  identify  and  correct  those  procurement  procedures  related  to  contractual 
incentives,  software  reuse,  and  capitalization,  which  contribute  to  an  erosion  of  the  DoD 
software  industrial  base.  Actions  related  to  this  include  revising  software  procurement 
procedures  so  as  to  strengthen  the  industrial  base,  contributing  to  an  enhanced  competition, 
supporting  a  “best  value”  acquisition  strategy,  and  accommodating  commercial  interests. 

Some  aspects  of  defense  procurement  procedures,  specifically  those  related  to  reusability,  work 
breakdown  levels,  Federal  Acquisition  Regulation  (FAR)  procedures  for  capitalization  of 
software  tools,  software  copyright  and  data  right  procedures,  have  contributed  to  what  many 
industry  representatives  feel  is  a  marginal  business  environment.  As  a  result,  commercial  firms 
have  made  conscious  decisions  to  exclude  DoD  efforts  from  their  business  base.  A  modified 
contracting  process  for  software  sensitive  systems  which  focuses  on  the  use  of  contractual 
incentives,  modified  claims  to  software  data  rights,  and  increased  use  of  licensing  agreements 
and  copyrights  can  mitigate  the  current  situation. 

While  many  involved  with  systems  acquisition  are  comfortable  in  applying  and  tailoring  existing 
contract  mechanisms,  e.g.,  standards,  specifications,  contract  type,  statement  of  work 
requirements,  etc.,  for  hardware,  the  same  is  not  true  for  aspects  of  the  system’s  software.  A 
similar  problem  exists  for  monitoring  and  administrative  support  during  contract  execution.  As 
systems  become  increasingly  software  sensitive,  there  is  an  ongoing  need  to  refine  and  improve 
current  contracting  vehicles  and  methods  to  monitor  contracts.  Both  defense  and  commercial 
interests  are  served  by  integrating  awareness  of  computer  and  software  oriented  concerns  into 
the  contracting  environment,  while  capitalizing  on  experimental  application  of  prevailing 
commercial  practices. 

REQUIRED  ACTIONS: 

2-G  Review  acquisition  and  contracting  strategies  to  ensure  that  software  considerations  are 
adequately  addressed  in  realistic  cost,  schedule,  and  performance  terms. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  Continuous 
Estimated  cost:  No  direct  costs 
Priority:  1 

2-H  Initiate  cases  with  the  FAR  Council,  as  appropriate,  to  address  software-related  issues 
including  the  following: 

—  Redefinition  of  the  term  “software”  and  establishment  of  software  as  a  contractually 
deliverable  item; 

—  Intellectual  property  protections; 

—  Capitalization  of  software  products; 
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—  Reusable,  existing,  and  COTS  software  that  affect  system 
interoperability,  and  logistics;  and 

—  Technology  insertion  mechanisms. 

OPR:  OUSD(A) 

Estimated  time:  6  months 
Estimated  cost:  No  direct  costs 
Priority:  1 


performance, 
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3.  DoD  SOFTWARE  POLICIES  AND  STANDARDS 

ISSUE:  Hardware  oriented  DoD  policies,  standards,  and  guidance  are  not  effective  in  managing 
modem  software  sensitive  environments. 

Existing  DoD  policy,  standards  and  guidance  documents  regarding  software  and  systems  are 
identified  in  Annex  B.  DoD  software  studies  (Annex  E)  identify  the  need  for  revision  of 
government  software  policies.  While  these  studies  have  concentrated  on  weapon  system  or 
mission  critical  software  applications,  the  findings  are  often  applicable  to  information  systems. 
It  is  imperative  that  current  software  policies,  standards  and  guidance  be  made  more  consistent, 
more  timely  with  respect  to  modem  software  practices,  less  prone  to  misuse,  more  complete, 
and  more  readily  enforced.  A  major  objective  of  the  DoD  Software  Master  Plan  is  to  identify 
opportunities  for  improving  the  DoD  policies,  standards  and  guidance.  This  requires:  (1) 
consolidating  the  DoD  policies  for  automated  information  systems  and  mission  critical  systems; 
(2)  updating  applicable  DoD  system  policies  and  standards  to  reflect  software  impacts;  (3) 
updating  DoD  software  and  related  standards;  and  (4)  strengthening  DoD  advisory  role  in 
softw  are  export/import  policy. 

3.1  GOAL:  Consolidate  DoD  Policies  For  Automated  Information  Systems  And 
Mission  Critical  Systems 

Existing  acquisition  and  management  policies  focus  primarily  on  computer  hardware.  Although 
there  are  differences  in  procurement  law  for  AIS  and  mission  critical  systems,  there  are  large 
areas  of  commonality  between  the  two  communities  that  would  benefit  from  consistent  policy. 
A  need  exists  for  consistent,  current  and  rational  policy  for  computer  resource  acquisition  and 
planning  that  also  addresses  the  advances  made  in  software  management  and  technology. 

Consolidated  policy  should  integrate  existing  policy  to  the  maximum  extent  possible  and  provide 
a  baseline  for  implementing  further  policies  and  practices  in  response  to  top-level  acquisition 
management  and  policy  directions.  As  a  result  of  the  Defense  Management  Report  (DMR), 
AISs  are  now  under  the  cognizance  of  the  DAB.  A  natural  outgrowth  of,  and  a  derived 
requirement  from,  the  DMR  is  the  need  for  consistent  software  policy.  New  consolidated  policy, 
and  its  associated  documents,  should  emphasize  the  following  major  policy  elements: 

a.  A  single  DoD  focal  point  for  software  acquisition  policy  to  ensure  implementation, 
follow-through,  and  enforcement; 

b.  Mandatory  software  training  programs  for  upper  level  managers; 

c.  Tracking  of  software  costs  throughout  a  system  life  cycle; 

d.  Development  and  continual  update  of  a  Computer  Resources  Life-Cycle  Management  Plan 
to  be  certified  by  the  Service  Acquisition  Executive  and  then  submitted  to  the  DAB  as  part 
of  the  required  documentation  to  support  the  Milestone  I  decision; 

e.  Early  identification  of  software  related  risks  and  risk-management  strategies,  with  an 
emphasis  on  early  resolution  of  risk  items  ; 

f.  Mechanisms  to  promote  reuse  of  system  architectures  and  designs,  and.  where 
appropriate,  software  components; 

g.  Mechanisms  for  user  involvement  in  software  and  system  development; 

h.  Incentives  based  on  life-cycle  performance ; 

i.  Use  of  software  process  maturity  assessment  of  an  organization  as  a  source  selection 
criterion; 

j.  Software  documentation  requirements  to  address  operational  needs;  and 

k.  Criteria  for  mid-life  re-engineering  of  existing  software  systems. 
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Policies  should  be  as  technology  independent  as  practical  in  order  to  promote: 

a.  Adoption  of  modern  development  and  support  process  models.  Process  models  should  not 
be  so  rigidly  defined  as  to  inhibit  use  of  different/improved  models. 

b.  Incentives  for  development  of  effectively  reusable  software  assets,  including  systems 
architectures  and  interfaces. 

c.  Tailoring  of  software  documentation  requirements  to  those  necessary  for  cost  effective 
operational  support.  Policy  must  allow  for  modification  of  rights-in-data  provisions,  use  of 
electronic  media  deliverables  containing  system  documentation  object  bases,  and  other 
steps  required  to  enable  preservation  and  ease  of  access  to  the  necessary  and  sufficient 
design  information  needed  to  maintain/enhance  software  and  documentation  in  the  post 
deployment  software  support  environment. 

d.  Contractor  capitalization.  Incentives  for  contractors  to  capitalize  on  their  investments  can 
increase  their  productivity  and  can  also  reduce  life-cycle  costs.  The  development  and  use 
of  modem  practices  and  tools  provides  the  means  to  address  many  of  the  challenges 
related  to  risk-  reduction,  reuse,  and  life-cycle  cost  reduction. 

Policies  should  support  advancing  technology.  Many  current  government  software  policies  are 
based  on  outdated  approaches  to  the  software  development  process.  Policies  need  to  enable 
appropriate  use  of  rapid  prototyping,  reusable  and  COTS  software,  fourth  generation  languages, 
incremental  and  evolutionary  software  development  approaches,  software  risk  management, 
domain-specific  software  architectures,  object-oriented  software  design  and  development,  and 
other  approaches  based  on  new  technologies,  as  they  emerge. 

New  approaches  to  the  software  process,  while  often  promising  significant  improvements  in 
productivity  and  quality,  can  often,  in  their  initial  uses,  entail  significant  increases  in  risk  for 
software  managers  because  of  immaturity  of  supporting  technology  or  management  practices. 
Attaining  sufficient  maturity,  however,  usually  requires  full-scale  prior  use. 

The  policy  challenge,  therefore,  is  to  provide  the  means  to  reduce  the  risks  associated  with 
adoption  of  new  approaches,  and.  thus,  to  stimulate  the  use  of  more  cost-effective  approaches. 
Many  existing  policies  were  developed  in  order  to  accelerate  transitions  from  the  practices  and 
technology  of  the  1960s  to  the  practices  and  technology  of  the  1970s.  Where  these  policies 
succeeded  in  promoting  modern  and  efficient  practices  five  or  ten  years  ago,  they  are  now.  in 
some  cases,  impeding  progress.  Policies  should  recognize  explicitly  that  technological  capability 
is  continually  improving,  and  that  regular  policy  adjustments  are  required. 

REQUIRED  ACTIONS: 

3-A  Update,  consolidate,  and  promulgate  consistent  DoD  policy  and  guidance  for  the 
acquisition  and  life-cycle  management  of  software  sensitive  systems. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  12  months 
Estimated  cost:  No  direct  costs 
Priority:  1 

3-B  Consolidate  all  policy  and  oversight  responsibilities  with  regard  to  Ada,  emphasize  the 
mandate  to  use  Ada  and  enforce  that  mandate. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  3  months 
Estimated  cost:  No  direct  costs 
Priority:  1 
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3.2  GOAL:  Update  Applicable  DoD  System  Policies  And  Standards  To  Reflect 
Software  Impacts 

Software  is  an  essential  element  of  modern  defense  systems.  Accordingly,  it  is  imperative  that 
system  policies  and  standards:  (1)  recognize  the  impacts  of  software  on  the  acquisition  of 
systems;  and  (2)  specify  strategies  for  more  efficient  software  acquisition.  In  addition,  policies 
and  standards,  whether  system  or  software  unique,  should  be  consistent  in  their  support  of  DoD 
system  acquisition  objectives.  Examples  of  system  standards  that  currently  inadequately  support 
desired  DoD  software  policy  objectives  include:  MIL-STD-499  (system  engineering);  MIL- 
STD-785B  (reliability);  MIL-STD-881A  (work  breakdown  structure  and  cost  capturization) ; 
MIL-STD-1388  (logistics  support);  and  MIL-STD-1521B  (reviews  and  audits).  DoD  system 
level  policies  must  also  recognize  mechanisms  for  the  development  of  software  systems  that  can 
satisfy  certain  specific  system  level  requirements  provisions,  such  as  cost,  reliability', 
performance,  security  and  safety  properties,  with  very  high  levels  of  confidence. 

The  largest  share  of  software  costs  are  incurred  after  deployment  in  operations.  The  largest  cost 
driver  is  software  changes  not  anticipated  in  initial  design,  additional  interfaces,  human  factor 
adjustments,  and  unforeseen  performance  demands.  Increased  management  attention  is 
required  to  create  an  effective  interaction  between  system  engineering,  technology  base,  and 
operating  logistics  environments.  Emerging  software  engineering  practices  and  support  tool 
environments  show  promise  in  expediting  changes  while  retaining  reliability.  The  tool  sets  must 
be  designed  to  support  the  operational  environment  and  overall  integrated  logistics  posture 
throughout  the  entire  life  cycle. 

REQUIRED  ACTIONS: 

3-C  Establish  and  promulgate  DoD  system  engineering  and  logistics  policies  that  promote 
the  integration  and  application  of  development  and  support  activities  throughout  the 
system’s  life  cycle.  These  policies  must  address  all  relevant  functional  disciplines, 
including  software  engineering,  to  ensure  that  the  system  is  responsive  to  user 
requirements. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  12  months 
Estimated  cost:  No  direct  costs 
Priority:  1 

3-D  Identify  and  initiate  appropriate  actions  for  those  DoD  system  level  acquisition 
standards  that  require  modification  to  address  software  considerations;  and  promote 
incorporation  of  technological  advances  in  the  acquisition  and  support  processes. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  18  months 
Estimated  cost:  No  direct  costs 
Priority:  2 

3.3  GOAL:  Update  DoD  Software  And  Related  Standards 

As  noted  in  Annex  B,  there  are  a  large  number  of  existing  software  unique  standards,  many  of 
which  are  over  five  years  old,  although  a  five  year  review  cycle  is  an  integral  part  of  the 
standardization  process.  The  review  cycle  allows  sufficient  contractual  experience  to  be  gained 
so  as  to  identify,  capture  and  prepare  required  modifications.  As  experience  is  obtained,  it  is 
necessary  to  ensure  that  standards,  e.g.,  DOD-STD-2167A  (software  development)  and  DOD- 
STD-2168  (software  quality),  and  associated  handbooks  support  DoD  policy  objectives  and 
promote  incorporation  of  technological  advances  into  the  acquisition  and  support  processes. 
Data  standards  are  equally  significant  for  assuring  standard  software  development  and 
interoperability  of  software  applications. 
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REQUIRED  ACTIONS: 

3-E  Develop  and  recommend  pertinent  modifications  to  software  and  related  standards  and 
work  with  the  offices  of  primary  responsibility  (normally  Service  organizations)  to  ensure 
the  prompt  incorporation  of  required  changes.  Participate  in  commercial  standards 
activities,  initiating  them  when  appropriate,  to  avoid  development  of  DoD  specific 
standards. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  Continuous 
Estimated  cost:  No  direct  costs 
Priority:  2 

3.4  GOAL:  Strengthen  DoD  Advisory  Role  In  Software  Export/Import  Policy 

A  conflict  exists  between  the  DoD  needs  to:  (1)  develop  a  strong  industrial  software  base;  and 
(2)  ensure  national  security.  Software  is  a  critical  component  of  our  defense  systems. 
Uncontrolled  exportation  of  software  can  inadvertently  compromise  national  security  through 
the  release  of  critical  technology.  Unexamined  importation  of  software  and  supporting  hardware 
(i.e.  chip  sets)  renders  the  DoD  vulnerable  to  deliberate  subversion,  as  well  as  lack  of  industrial 
based  support  during  times  of  conflict.  It  is  essential  for  national  security  to  sustain  a  strong 
U.S.  software  industry. 

The  DoD  must  address  both  sides  of  these  conflicting  issues.  The  DoD  must  protect  critical 
software  technologies  and  support  environments.  DoD  contractual  and  security'  procedures 
need  to  be  updated  and  official  positions  established  for  technology  transfer.  In  an  advisory  role, 
the  DoD  must  take  an  active  and  aggressive  stance  in  promoting  U.S  intellectual  property  rights 
through  the  objectives  of  the  General  Agreement  on  Tariffs  and  Trade,  the  World  Intellectual 
Property  Organization,  and  CoCom  (Cooperation  Committee).  The  DoD  must  also  work  with 
the  European  community  as  it  transitions  to  “Europe  1992.” 

REQUIRED  ACTIONS: 

3-F  Recommend  policy  that  addresses  DoD  interests  in  security,  foreign  trade  barriers  and 
tariffs,  intellectual  property  protection,  and  the  importance  of  open  markets  and 
reciprocal  trade  strategies. 

OPR:  ODUSD(I&IP) 

Estimated  time  to  accomplish:  Continuous 
Estimated  cost:  No  direct  costs 
Priority:  3 
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4.  PERSONNEL 

ISSUE:  A  significant  shortage  of  sufficiently  qualified  software  personnel  currently  exists  at  all 
levels  within  the  DoD. 

In  order  to  strengthen  the  capabilities  of  the  software  workforce  at  all  levels  within  the  DoD, 
actions  must  be  taken  to  improve  the  ability  of  the  DoD  to  attract  and  retain  talented  software 
professionals.  There  are  a  number  of  reasons  why  the  DoD  must  maintain  an  internal  base  of 
software  expertise: 

a.  The  DoD  must  have  internal  expertise  in  order  to  effectively  formulate  specifications  for 
software  acquisitions. 

b.  The  DoD  must  retain  the  ability  to  represent,  as  a  customer,  its  own  interests  since  they  are 
often  at  variance  with  the  interests  of  the  producers. 

c.  DoD  policies,  standards,  and  guidelines,  require  continual  revision  and  update.  Personnel 
involved  in  the  development  of  these  standards  and  policies  must  understand  the 
technology. 

d.  Program  managers  and  internal  DoD  life-cycle  support  personnel  must  be  able  to 
effectively  represent  the  DoD  interest  and  make  programmatic  decisions  in  a  technically 
informed  way.  The  ability'  to  assess  risks  associated  with  adoption  of  new  approaches  to 
software  development  derives  from  technical  understanding.  One  of  the  key  inhibitors  to 
adoption  of  modern  technology  in  DoD  acquisitions  is  conservative  decision-making  by- 
acquisition  and  support  personnel  who  have  insufficient  technical  background  to  effectively 
judge  tradeoffs  between  risks  and  benefits. 

A  major  objective  of  the  DoD  Software  Master  Plan  is  to  identify  opportunities  to  strengthen  the 
capabilities  of  the  DoD  software  workforce.  This  requires:  (1)  improving  personnel  policies  to 
retain  and  develop  qualified  personnel;  and  (2)  improving  education  and  training. 

4.1  GOAL:  Improve  Personnel  Policies  To  Retain  And  Develop  Qualified 
Personnel 

The  software  workplace  has  changed  dramatically  over  the  past  decade  but  civil  service  and 
military  personnel  policies  have  not  adequately  reflected  these  changes.  For  personnel  with  the 
critical  skill  mixes  required  for  the  development,  maintenance  and  evaluation  of  software,  the 
DoD  is  becoming  less  competitive.  As  a  result,  the  DoD  is  increasingly  less  effective  in 
technical  management  areas  and  in  solving  complex  technical  problems. 

REQUIRED  ACTIONS: 


4-A  Define  career  paths  and  salary  incentives  for  all  civilian  software  professionals.  Broaden 
the  career  paths  of  those  civilian  software  professionals  above  the  GS/GM-15  level. 

OPR:  OASD(FM&P)  with  support  from  DoD  components 

Estimated  time  to  obtain  Office  of  Personnel  Management  approval  of  new 
career  paths:  24  months 
Estimated  cost:  No  direct  costs 
Priority:  I 

4-B  Define  career  paths  and  salary  incentives  for  military  software  professionals  up  to  and 
including  the  general  flag  rank. 

OPR:  OASD(FM&P),  with  support  from  the  Military  Departments 

Estimated  time  to  obtain  agreement  from  the  services  on  broadened  career  path 

to  flag  rank  and/or  service  plans  for  incentives:  30  months 

Estimated  cost:  No  direct  costs 

Priority:  1 
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4.2  GOAL:  Improve  Education  And  Training 

Improving  DoD  software  education  and  training  programs  is  critical  for  two  reasons.  First, 
software  affects  almost  everyone's  ability  to  successfully  perform  his/her  job.  Second,  the  rapid 
changes  in  software  technology  and  management  practices  often  results  in  the  obsolescence  of 
technical  skills. 

Modern  software  engineering  consists  of  a  combination  of  technical  and  managerial  skills.  Most 
software  professionals  have  entered  the  field  via  the  technical  route  and  have  not  had  the 
opportunity  to  pursue  the  managerial  aspects  of  software  engineering.  Individuals  who  have 
entered  the  field  via  a  non-technical  background  have  an  enormous  difficulty  in  understanding 
the  technical  complexity  of  large  systems  and  in  communicating  with  the  technical  experts. 
However,  the  field  is  rapidly  advancing,  with  new  concepts  and  technologies  continually 
emerging  that  must  be  understood  by  both  management  and  technical  personnel  if  they  are  to  be 
effectively  included  in  DoD  systems.  This  situation  can  only  be  improved  through  the  aggressive 
application  of  professional  level  education  and  training. 

With  software  as  the  focus  of  functionality’  and  flexibility  of  the  complex  and  critical  systems 
developed  by  the  DoD,  there  exists  a  need  to  raise  the  level  of  professionalism  for  the 
acquisition,  management,  development  and  post  deployment  support  of  these  systems.  DoD 
should  strive  to  formalize  the  software  profession. 

REQUIRED  ACTIONS: 

4-C  Develop  and  implement  Service  software  training  programs  that  include  provisions  for 
post  graduate  s.  ftware  engineering  education  for  DoD  employees  on  a  competitive  basis. 
These  programs  should  be  centrally  funded  in  the  Services  for  continued  application. 
OPR:  Military  Departments 

Estimated  time  to  accomplish:  12  months  for  plans  then  continuous 
Estimated  cost:  $2M  per  year 
Priority:  1 

4-D  Develop  software  awareness  course  for  all  Senior  Executive  Service  and  General/Flag 
level  officers  and  a  software  acquisition  management  course  for  those  executives 
involved  in  the  acquisition  process.  This  could  be  based  on  similar  programs  such  as  the 
current  Air  Force  Bold  Stroke  program  and  the  Navy’s  Executive  Symposium  on 
Information  Technology.  The  courses  should  range  from  3  to  5  days  in  order  to  include 
the  significant  software  issues  and  technology. 

OPR:  The  National  Defense  University,  with  support  from  the  OUSD(A) 

Acquisition  Training  and  Career  Development  Policy  Office 

Estimated  time  to  accomplish:  12  months 

Estimated  cost:  $300K 

Priority:  2 

4-E  Coordinate  efforts  of  the  Military  Department  schools  (Service  academies  and 
postgraduate  institutions),  in  conjunction  with  academia  and  the  Software  Engineering 
Institute,  to  develop  accredited  software  engineering  programs  that  address  DoD  needs. 
OPR:  OUSD(A)  Acquisition,  Training  and  Career  Development  Policy  Office 
Estimated  time  to  accomplish:  24  months 
Estimated  cost:  $300K  per  year 
Priority:  2 

4-F  Develop  a  DoD  program  which  allows  software  professionals  to  attend  postgraduate 
programs  in  return  for  continuing  to  work  for  DoD  for  a  specified  length  of  time.  This 
program  should  be  targeted  for  recruitment  of  entry  level  college  graduates  as  well  as 
junior  professionals  already  working.  The  program  could  be  modeled  on  the  Uniform 
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Medical  School  program  currently  in  force  to  attract  doctors.  The  goal  is  to  attract  the 
highest  quality  professionals  into  the  pool  of  software  professionals. 

OPR:  TBD 

Estimated  time  to  accomplish:  12  months  for  program  followed  by  annual  awards 
Estimated  cost:  $50K  for  first  year;  $500K  for  annual  scholarships 
Priority:  2 

4-G  Coordinate  efforts  of  the  DoD  Joint  Service  schools  (National  Defense  University, 
Defense  Systems  Management  College,  Industrial  College  of  the  Armed  Forces)  to 
integrate  software  acquisition  and  development  programs  into  existing  courses. 

OPR:  OUSD(A)  Acquisition,  Training  and  Career  Development  Policy  Office 
Estimated  time  to  accomplish:  Continuous 
Estimated  costs:  No  direct  costs 
Priority:  3 

4-H  Establish  mandatory  software  engineering  educational  requirements  for  all  DoD 
technical  and  contractual  personnel  involved  in  the  acquisition  process.  Education 
requirements  (including  on  the  job  training  and  continuing  education)  should  be  tailored 
to  the  specific  job  category  identified. 

OPR:  OUSD(A)  Acquisition,  Training  and  Career  Development  Policy  Office 
Estimated  time  to  accomplish:  24  months 
Estimated  costs:  No  direct  costs 
Priority:  3 
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5.  SOFTWARE  TECHNOLOGY  BASE  AND  TRANSITION 

ISSUE:  The  current  management,  funding,  and  transition  of  the  software  technology  base  are 
insufficient. 

The  maintenance  of  a  strong  technology  base  entails  more  than  simply  sustaining  the  research 
activity.  It  also  requires  me  brokering  of  technology  transition  relationships,  the  advancement  of 
an  infrastructure  for  engineering  and  prototyping,  and  the  fostering  of  an  active  and  independent 
research  community.  One  of  the  major  reasons  for  the  U.S.  strength  in  technology  is  the 
strength  of  the  research  community  and  the  means  by  which  innovation  in  this  community 
translates  into  products  in  the  marketplace  and  in  Defense  systems.  The  effectiveness  of  the 
DoD  software  technology  base  can  be  significantly  strengthened  by  (1)  improving  its 
management;  (2)  increasing  its  funding;  and  (3)  accelerating  technology  transition. 

5.1  GOAL:  Improve  Management  Of  The  DoD  Software  Technology  Base 

The  technology  base  investment  has  yielded  very  significant  results  when  effectively  managed. 
However,  technology  base  programs  sometimes  focus  on  topics  that  are  excessively  near-term 
and  constrained,  that  are  irrelevant  to  DoD  needs,  or  that  do  not  strengthen  DoD’s  position  vis- 
a-vis  the  producers  from  whom  it  must  acquire  software  and  systems. 

Program  managers  for  technology  base  programs  must  have  scientific  knowledge,  maturity  of 
technical  judgement,  an  effective  understanding  of  contracting  and  acquisition  principles,  and  an 
understanding  of  the  means  to  manage  for  accomplishment  in  the  technology  base  community. 
Because  of  the  abstract  nature  of  the  scientific  results  produced,  software  research  places 
particular  demands  on  program  management  skills. 

Effective  technology  base  management  strategy  has  proven  to  have  impact  far  in  excess  of  the 
DoD  investment.  Successful  technology’  base  investments  are  generally  based  on  a  principled 
investment  strategy,  even  if  breakthroughs  are  often  serendipitous.  The  principles  upon  which 
this  investment  strategy  is  based  include  the  following: 

a.  Use  the  software  technology  base  to  promote  the  development  of  open  systems 
architectures.  Technology  base  investment  and  acquisition  strategy  should  provide 
incentives  to  industry  to  create  solutions  that  enable  customer  flexibility  and  that  reduce 
customer  adoption  risk.  The  DoD  can,  as  a  customer,  use  the  software  technology  base 
activity  to  help  foster  open  architecture  approaches  that  can  lead  to  standards  that  are 
accepted  commercially  and  in  defense. 

b.  Maintain  a  mixed  strategy  in  the  technology  base.  Excessively  tight  coordination  among 
basic  research  sponsors  in  the  government  can  result  in  a  stifling  of  creativity  and  diversity 
in  new  ideas  explored.  In  areas  of  high  risk,  several  approaches  may  be  pursued  that  may 
not  be  intellectually  consistent,  but  that  provide  coverage  over  the  range  of  possible 
outcomes. 

c.  Foster  software  technology'  to  support  hardware  innovation.  Software  technology  is  subject 
to  periodic  major  hardware  innovations,  such  as  the  shift  that  occurred  from  batch 
computing  to  timesharing  systems,  then  to  personal  computing,  then  to  networked 
workstations,  and  now  to  heterogeneous  distributed  computing  with  workstations  and 
servers.  DoD  must  avoid  surprise  and  be  able  to  support  these  innovations.  The  continual 
succession  of  major  hardware  shifts  reduces  incentive  for  industry  to  invest  in  long  term 
software  approaches  unless  costs  and  risks  can  be  assessed  and  controlled. 

d.  Attend  to  technology  base  human  resources  needs.  Excessive  volatility  of  funding  can 
often  result  in  the  disbanding  of  strong  research  groups  or  in  the  migration  of  university 
researchers  to  industry,  where  they  have  less  impact  on  producing  the  next  generation  of 
researchers,  technical  leaders,  and  educators. 
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e.  Simplify'  the  6. 1/6.2  contracting  process  by  providing  an  efficient  fast  channel.  Many 
researchers  and  research  institutions  are  discouraged  from  working  with  DoD  because  of 
procedural  difficulties,  perceived  and  real,  associated  with  initiating  research  contracts. 

f.  Keep  the  Research  and  Development  (R&D)  infrastructure  current.  Equipment  and 
research  facility  support  should  be  provided  to  researchers  to  enable  them  to  remain 
current  with  the  rapid  pace  of  technological  change. 

g.  Keep  a  long  term  focus.  Long  term  investment  is  not  the  same  as  exploratory  investment. 
It  is  often  expedient  and  necessary  for  research  program  managers  to  redirect  technology 
base  activity  to  satisfy-  nearer  term  needs,  but  the  downstream  costs  should  be  recognized. 

h.  Coordinate  R&D  investment  strategy.  Program  managers  of  research  programs  in  DoD 
should  coordinate  with  potential  users  of  research  results  and  with  program  managers  in 
related  research  areas  before  con  fitting  to  research  investment  plans. 

i.  Recognize  the  stages  of  re  sear-  iaturity.  Program  managers  responsible  for  the  software 
technology  base  must  take  explicit  steps  to  limit  adoption  risk  as  R&D  results  mature. 

REQUIRED  ACTIONS- 

5-A  Use  the  above  management  principles  as  a  guide  to  the  performance  evaluations  for 
software  technology  base  program  managers. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  Continuous 
Estimated  cost:  No  direct  costs 
Priority:  1 

5.2  GOAL:  Increase  The  Software  Technology  Base  Investment 

DoD’s  software  problems  will  not  be  solved  purely  via  policies  and  standards.  An  integrated 
DoD  software  strategy  involving  both  software  management  and  technology  initiatives  will  make 
a  much  larger  difference  in  res  living  DoD’s  current  and  future  software  problems. 

Numerous  studies  have  recommended  significant  increases  in  DoD’s  investment  in  software 
technology  research.  (See  Annex  E.)  The  commercial  software  marketplace  is  often  decoupled 
from  many  central  DoD  software  concerns,  such  as  embedded  real-time  software,  Ada,  security, 
and  ultrareliability.  Thus  DoD  cannot  count  on  commercial  technology  to  solve  all  of  its 
software  problems.  On  the  other  hand,  an  active  DoD  software  technology  strategy  emphasizing 
commercialization  and  open  interfaces  can  incentivize  commercial  software  organizations  to 
build  DoD-critical  capabilities  into  commercial  software  products. 

This  Master  Plan  has  deferred  the  inclusion  of  a  detailed  DoD  Software  Technology-  Plan  in 
order  to  decouple  the  approval  cycle  of  urgent  software  management  recommendations  from  the 
approval  cycle  for  a  major  software  technology  investment  program.  The  following  list  identifies 
possible  topics  to  be  addressed  in  the  development  of  a  DoD  Software  Technology  Plan. 

a.  Software  engineering  environment  frameworks.  These  are  central  to  the  integration  of 
technology  capabilities  and  the  stimulation  of  commercial  software  tools  responsive  to 
DoD  needs. 

b.  Software  engineering  tools,  including  requirements,  design,  code,  instrumentation  and 
analysis,  test,  configuration  management,  and  post-deployment  support  tools. 

c.  Prototyping  tools  and  their  underlying  prototyping  support  capabilities  to  support 
requirements  engineering  and  design. 

d.  Capabilities  for  classification,  retrieval,  and  evaluation  of  reusable  software  assets, 
including  code  components,  interface  definitions,  test  cases,  requirements  specifications 
fragments,  etc. 
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e.  Domain-specific  software  architectures,  application  generators,  and  domain-specific 
computational  models.  Opportunities  exist  in  domains  such  as  automatic  target 
recognition,  avionics,  navigation,  CrI,  and  simulation  and  planning,  as  well  as 
infrastructure  areas  such  as  real-time  kernels,  image  processing,  and  signal  processing. 

f.  Software  re-engineering.  Apply  or  retrofit  modern  software  technology  (e.g. ,  decompilers, 
code  analyzers,  testing  aids,  configuration  management  aids,  Ada  transition  aids)  to  DoD’s 
huge  inventory  of  antiquated  software. 

g.  Management  tools,  including  metrics  and  cost  estimation.  Candidates  include  group 
coordination  and  decision  aids,  knowledge-based  software  risk  management  aids, 
hypermedia  and  software  visualization  technology,  gaming  aids  for  training  software 
managers,  and  automated  support  of  modem  software  process  models. 

h.  Ultrareliable  and  secure  software. 

i.  Distributed  and  parallel  software.  Applications  include  large  scientific  and  engineering 
modeling,  embedded  real-time  applications,  and  AIS  systems. 

j.  Scalable  Artificial  Intelligence  (AI)  capabilities,  interoperable  knowledge  base  services, 
interoperability  between  AI  services  and  conventional  software  services,  and  verification 
and  validation  for  AI  applications. 

k.  Systems  software,  including  support  for  security,  ultrareliability,  and  real-time. 

l.  Computer  science  base  critical  to  addressing  future  DoD  needs  in  software  reliability, 
security,  parallelism,  and  distributed  real-time. 

m.  Technology  transition  support,  including  shadow  projects,  mid-life  re-engineering,  and 
prototyping. 

REQUIRED  ACTIONS: 

5-B  Develop  the  DoD  Software  Technology  Plan  and  take  appropriate  action  to  obtain  the 
required  additional  funding.  The  Plan  will  be  implemented  by  the  Services  and  Agencies. 
OPR:  OUSD(A) 

Estimated  time  to  accomplish:  6  months 
Estimated  cost:  No  direct  costs 
Priority:  1 

5.3  GOAL:  Accelerate  Technology  Transition 

Technology  transition  acceleration  involves  much  more  than  just  shortening  the  process  from 
DoD  basic  research  to  operational  systems  developments.  Technology  users  (consumers), 
technology  suppliers  (producers),  and  the  technology  transition  infrastructure  must  be 
considered  when  making  improvements.  Software  technology  comes  from  several  sources: 
research,  DoD  mission  systems,  DoD  support  systems,  other  agencies,  and  the 
commercial/industrial  marketplace. 

The  following  set  of  issues  must  be  addressed  in  order  to  enhance  successful  technology 
transition: 

a.  Technology  transition  incentives  for  consumers.  Inhibitors  to  transition  include:  (1)  extra 
up-front  effort  to  assimilate  new  technology;  (2)  risk  of  using  new  technology;  (3)  contract 
selections  based  excessively  on  cost  and  schedule  rather  than  life-cycle  quality  and 
productivity;  and  (4)  rights-in-data  clauses  requiring  unlimited  rights  to  software 
technology  used  to  develop  systems.  Data  rights  provisions  must  enable  both  controllable 
evolution  and  appropriate  commercialization  by  developers. 
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b.  Technology  transition  incentives  for  suppliers.  Inhibitors  include:  (1)  inflexible  rights-in- 
data  clauses  for  vendors;  and  (2)  university  promotion  criteria  that  emphasize  publication. 

c.  Standards  and  flexibility'.  Inhibitors  include  lack  of  interface  or  modularity  standards.  On 
the  other  hand,  overly  specific  standards  can  inhibit  downstream  transition. 

d.  Transition  support  planned  for  post  deployment.  Inhibitors  include:  (1)  maintenance 
contracts  that  create  disincentives;  (2)  inadequate  change  coordination  across 
interoperating  systems;  (3)  acquisition  of  commercial  packages  without  provision  for 
tailoring;  (4)  development  shortcuts;  and  (5)  shortfalls  in  “nonstop”  hardware-software 
operating  capabilities  for  operational  systems. 

e.  Consumers’  readiness  for  technology  transition.  Inhibitors  include:  (1)  difficulty  to  jump 
to  much  higher  level  technology;  and  (2)  organizational  reluctance  to  accept  risks  and 
changes. 

f.  Technology  supplier’s  maturity.  Inhibitors  include:  (1)  failure  to  provide  seed  funds  to 
reduce  risks;  (2)  failure  to  identify  consumers;  and  (3)  failure  to  demonstrate  need  for  the 
new  technology. 

g.  Technology  maturity.  Inhibitors  include:  (I)  immaturity  of  new-technology  prototypes;  and 
(2)  failure  to  address  issues  of  robustness  and  scale. 

Technology  transition  can  be  accelerated  by  sponsoring  technology  initiatives  to  support 
technology  transition  and  developing  a  process  for  assessing  and  monitoring  technology 
transition.  Contracting,  personnel,  and  life-cycle  issues  associated  with  software  technology 
transition  are  addressed  in  other  chapters. 

The  following  list  identifies  possible  technology  initiatives  in  support  of  technology  transition 
which  may  be  addressed  in  the  DoD  Software  Technology  Plan. 

a.  Promote  shadow  projects.  Shadowing  an  ongoing  project  enables  direct  funding  of  risk 
while  providing  realistic  technical  context  and  realistic  inputs  for  a  development.  This 
allows  technology  to  be  experimentally  transitioned  and  executed  with  the  result 
compared  to  the  baseline  development  effort. 

b.  Promote  standard  open  interfaces.  Standard  open  interfaces  and  domain-specific  software 
architectures  facilitate  transition  of  improved  technology  and  reuse.  These  efforts  provide 
a  basis  for  development  of  software  repositories  and  catalogs. 

c.  Institute  software  mid-life  cost-effectiveness  reviews  and  attendant  upgrades.  These 
techniques  can  facilitate  transitioning  of  modern  technology  such  as  COTS  and  Ada  into 
existing  older  systems. 

d.  Develop  catalogs  and  repositories  for  software  architectures,  interfaces,  components,  and 
other  assets.  Application  specific  catalogs  will  enable  technology  identification,  selection, 
and  comparison  in  terms  of  problem  features.  Repository  management  schemes  need  to 
be  developed  for  charging  users,  allocating  proceeds,  funding  productization,  and 
protecting  proprietary  interests.  Technology'  suppliers  need  incentives  to  provide  product 
and  interface  data  for  use  in  repositories  and  catalogs.  Repositories  can  enable 
cooperation  among  producers  and  consumers  in  establishing  common  architectures, 
interfaces,  and  validation  mechanisms. 

e.  Develop  an  information  clearinghouse  to  disseminate  software  technology  evaluation  and 
information.  Examples  include  the  Ada  Information  Clearinghouse  and  the  Software 
Technology  Support  Center,  which  provide  information  regarding  compiler  validation  and 
evaluation,  performance,  newsletters,  electronic  mail  bulletin  boards,  focused  supplier- 
consumer  workshops,  and  other  pertinent  information. 
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f.  Develop  a  process  for  assessing  and  monitoring  technology  transition.  The  DARPA- 
sponsored  Software  Engineering  Institute  (SEI)  has  developed  a  Process  Maturity 
Assessment  for  rating  the  software  development  process  and  practices  within  a  DoD  or 
contractor  organization.  Similar  checklists  and  process  assessment  techniques  are  needed 
to  evaluate  and  improve  technology  transition  practices.  Elements  of  a  transition 
assessment  could  include  consideration  of  incentive  structures  for  technology  producers 
and  consumers,  evidence  of  workable  risk  and  cost  assessments  for  technology  consumers, 
validation  mechanisms  for  technology  producers,  and  evidence  of  life  cycle  impact 
assessment  for  near-term  technology  selections. 

REQUIRED  ACTIONS: 

5-C  Develop  a  plan  and  implementation  strategy  to  establish,  coordinate,  and  sustain  DoD 
application  software  repositories,  catalogs,  and  application-specific  software 
architectures.  The  plan  should  address  definition  of  effectiveness  metrics  for 
repositories  and  catalogs. 

OPR:  DARPA  and  DoD  components 
Estimated  time  to  accomplish:  12  months 
Estimated  cost:  $  1M 
Priority:  2 

5-D  Establish  a  software  information  clearinghouse. 

OPR:  OUSD(A) 

Estimated  time  to  accomplish:  12  months  to  establish 
Estimated  cost:  $500K  per  year  to  maintain 
Priority:  3 

5-E  Develop  a  process  for  assessing  and  monitoring  the  technology  transition  capability  of 
DoD  organizations. 

OPR:  DARPA  and  DoD  components 
Estimated  time  to  accomplish:  24  months 
Estimated  cost:  $  1M  per  year 
Priority:  3 
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6.  ACTION  SUMMARY,  PRIORITY,  FUNDING,  AND  SCHEDULE 

This  chapter  provides  a  summary,  priority,  funding  and  schedule  for  each  of  the  required  actions 
identified  in  Chapters  2  through  5. 

Table  6-1  lists  the  priority  assigned  to  each  required  action.  Actions  are  prioritized  on  a  scale  of 
#1  to  #3  with  #1  being  most  important.  Actions  are  identified  by  the  number/letter  pair 
assigned  in  Chapters  2  through  5  and  by  a  brief  phrase,  summarizing  the  action.  Because  it  is  not 
possible  to  capture  the  full  meaning  of  each  action  in  a  single  phrase,  the  reader  is  advised  to 
refer  to  the  full  text  associated  with  each  action,  provided  in  Chapters  2  through  5. 

The  action  determined  to  be  most  significant  in  the  implementation  of  this  DoD  Software  Master 
Plan  is  the  designation  of  an  office  by  the  Deputy  Secretary  of  Defense  (Action  #2-A)  to  serve  as 
a  focal  point  within  the  DoD  for  software.  This  office  should  have  primary  responsibility  for 
identifying,  managing,  integrating  and  implementing  software  acquisition  and  life  cycle 
management  policy.  Table  6.1  also  includes  the  schedules  associated  with  all  actions.  Schedules 
have  been  based  upon  a  start  date  of  fiscal  year  1991.  Table  6-1  also  provides  a  financial  summary 
of  the  estimated  DoD  funds  required  for  completion  of  the  actions  identified  in  Chapters  2 
through  5. 

It  is  important  to  note  that  the  funding  profile  shown  in  Table  6-1  does  not  represent  the  total 
additional  DoD  funding  that  is  required  to  address  the  software  problems  within  the 
Department.  No  attempt  has  been  made  to  provide  funding  allocations  for  those  actions  that  are 
primarily  based  upon  internal  DoD  activities  such  as  organizational  changes  and  coordination 
efforts,  for  which  there  are  no  direct  costs.  The  total  amount  of  funding  required  is  expected  to 
be  significantly  higher,  particularly  with  efforts  such  as  the  scaling  up  of  the  software  technology 
base.  The  OUSD(A)  should  be  responsible  for  updating  these  schedules  and  funding  profiles 
accordingly. 
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Table  6-1  Action  Summary,  Prioritization,  Schedule,  and  Funding 


Action  Number  and  Summary 


2-A  Designate  office  as  SW  focal  point 


2-B  Ensure  SW  addressed  within  DAB  structure 


2-C  Ensure  TQM  techniques  used  for  SW 


2-D  Define  SW  risk  management  framework 


2-E  Establish  metric  tool  "Consumer's  Union" 


2-F  Propose  technology  insertion  projects 


2-G  Review  acq.  &  contracting  strategies  for  SW  issues 


2-H  Initiate  cases  with  FAR  Council  on  SW  issues 


3-A  Consolidate  SW  directives/policies/guidance 


3-B  Consolidate  Ada  policy  and  oversight 


3-C  Establish  system  policies  to  address  SW  support 


3-D  Review  system  acq.  strategies  for  SW  issues 


3-E  Update  software  and  related  standards 


3-F  Revise  software  export/import  policy 


4-A  Define  civilian  SW  career  paths  and  salary  incentives 


4-B  Define  military  SW  career  path  to  General/Flag  rank 


4-C  Dev.  service  SW  training  plans  leading  to  adv.  degree 


4-D  Develop  SW  awareness  and  SW  acq.  mgt.  courses 


4-E  Develop  accredited  SE  programs 


4-F  Develop  DoD  SE  scholarship  program 


4-G  Integrate  SW  programs  into  DoD  Joint  Service  School 


4-H  Establish  SE  educational  requirements 


5-A  Use  key  principles  to  evaluate  tech  base  managers 


5-B  Develop  SW  Technology  Plan 


5-C  Develop  plan  for  DoD  SW  repositories 


5-D  Establish  SW  Information  Clearinghouse 


5-E  Develop  tech  transition  assessment  process 
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ACRONYMS 


AIS 

Automated  Information  Systems 

C3I 

Command,  Control,  Communications,  and  Intelligence 

COTS 

Commercial  Off-The-Shelf 

DAB 

Defense  Acquisition  Board 

DARPA 

Defense  Advanced  Research  Project  Agency 

DMR 

Defense  Management  Report 

DoD 

Department  of  Defense 

DOD-STD 

Department  of  Defense  Standard 

FAR 

Federal  Acquisition  Regulation 

MIL-STD 

Military  Standard 

ODUSD(I&IP) 

Office  of  the  Deputy  Under  Secretary  of  Defense  (Industrial  and  International 
Programs) 

OASD(FM&P)  Office  of  the  Assistant  Secretary  of  Defense  (Force  Management  and 
Personnel) 

OPR 

Office  of  Primary  Responsiblity 

OSD 

Office  of  the  Secretary  of  Defense 

OUSD(A) 

Office  of  the  Under  Secretary  of  Defense  (Acquisition) 

PDSS 

Post  Deployment  Software  Support 

R&D 

Research  and  Development 

S&T 

Science  and  Technology 
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